As the title suggest, see below a snippet for a conversation from the trace for "FindConversation" against Office365.

As you can see, the ChangeKey is "CQAAAA==" for all the items (across conversations), and interesting enough, it is the same as in the documentation for FindConversation

https://msdn.microsoft.com/en-us/library/office/ff406144(v=exchg.150).aspx

Is this a known issue?

       <Conversation xmlns="http://schemas.microsoft.com/exchange/services/2006/types">
            <ConversationId Id="AAQkADMwZjkyMjExLTMzMGUtNGU5MS04OWIzLTAyY2ExYjM2ZjFiMgAQAB2NeP3GTQlDp5B7AWesrrw=" />
            <ConversationTopic>Kid's turning the dog green again</ConversationTopic>
            <UniqueRecipients>
              <String>John Smith</String>
            </UniqueRecipients>
            <GlobalUniqueRecipients>
              <String>John Smith</String>
            </GlobalUniqueRecipients>
            <UniqueSenders>
              <String>John Smith</String>
            </UniqueSenders>
            <GlobalUniqueSenders>
              <String>John Smith</String>
            </GlobalUniqueSenders>
            <LastDeliveryTime>2014-11-26T16:21:37Z</LastDeliveryTime>
            <GlobalLastDeliveryTime>2014-11-27T14:09:09Z</GlobalLastDeliveryTime>
            <HasAttachments>false</HasAttachments>
            <GlobalHasAttachments>false</GlobalHasAttachments>
            <MessageCount>1</MessageCount>
            <GlobalMessageCount>4</GlobalMessageCount>
            <UnreadCount>0</UnreadCount>
            <GlobalUnreadCount>0</GlobalUnreadCount>
            <Size>16099</Size>
            <GlobalSize>28992</GlobalSize>
            <ItemClasses>
              <ItemClass>IPM.Note</ItemClass>
            </ItemClasses>
            <GlobalItemClasses>
              <ItemClass>IPM.Note</ItemClass>
            </GlobalItemClasses>
            <Importance>Normal</Importance>
            <GlobalImportance>Normal</GlobalImportance>
            <ItemIds>
              <ItemId Id="AAMkADMwZjkyMjExLTMzMGUtNGU5MS04OWIzLTAyY2ExYjM2ZjFiMgBGAAAAAAC/m9YT3n+7RbfoU4MvIUlwBwDO121Po4OqQ7Wo59kdWfWgAAAAAAEMAADO121Po4OqQ7Wo59kdWfWgAAASN40cAAA=" ChangeKey="CQAAAA==" />
            </ItemIds>
            <GlobalItemIds>
              <ItemId Id="AAMkADMwZjkyMjExLTMzMGUtNGU5MS04OWIzLTAyY2ExYjM2ZjFiMgBGAAAAAAC/m9YT3n+7RbfoU4MvIUlwBwDO121Po4OqQ7Wo59kdWfWgAAAAAAEJAADO121Po4OqQ7Wo59kdWfWgAAANAp25AAA=" ChangeKey="CQAAAA==" />
              <ItemId Id="AAMkADMwZjkyMjExLTMzMGUtNGU5MS04OWIzLTAyY2ExYjM2ZjFiMgBGAAAAAAC/m9YT3n+7RbfoU4MvIUlwBwDO121Po4OqQ7Wo59kdWfWgAAAAAAEJAADO121Po4OqQ7Wo59kdWfWgAAANAp24AAA=" ChangeKey="CQAAAA==" />
              <ItemId Id="AAMkADMwZjkyMjExLTMzMGUtNGU5MS04OWIzLTAyY2ExYjM2ZjFiMgBGAAAAAAC/m9YT3n+7RbfoU4MvIUlwBwDO121Po4OqQ7Wo59kdWfWgAAAAAAEJAADO121Po4OqQ7Wo59kdWfWgAAANAp23AAA=" ChangeKey="CQAAAA==" />
              <ItemId Id="AAMkADMwZjkyMjExLTMzMGUtNGU5MS04OWIzLTAyY2ExYjM2ZjFiMgBGAAAAAAC/m9YT3n+7RbfoU4MvIUlwBwDO121Po4OqQ7Wo59kdWfWgAAAAAAEMAADO121Po4OqQ7Wo59kdWfWgAAASN40cAAA=" ChangeKey="CQAAAA==" />
            </GlobalItemIds>
            <LastModifiedTime>2014-12-05T19:12:48Z</LastModifiedTime>
            <InstanceKey>AQAAAAAAAQABAAAADQKSGAAAAAA=</InstanceKey>
            <HasIrm>false</HasIrm>
            <GlobalHasIrm>false</GlobalHasIrm>
          </Conversation>

• Edited by Erez Katz Monday, March 30, 2015 9:27 AM

It does seem to be unique to FindConversations, but I've certainly never noticed it before. Are you using the change key for something in this scenario? Typically change key is used by the server to determine if a change has happened between the time you retrieved an item and the time you modified it. To modify the item you'd need to do a GetItem on it anyway, which would bring down the real change key.

It is a priority for my application that what I display to the user is consistent with the server.

If the user changed the item (change the IsRead flag for instance or other meta data), then that change must be reflected in the application without delay, when I pull the conversation. According to the changeKey, I know if I need to re-fetch the item.

It would be a shame if after I pull all the conversation and item ids, I would do a bind on items that did not really change just because the changeKey that I got in FindConversations is hardcoded. 

Now my target audience more corporate exchange servers, not as much as office365, so I could live with this bug but I need to know. Otherwise what is the point to send a ChangeKey if the value is guaranteed to be wrong?

I see. So you're storing the change keys from a previous pull, then comparing it to determine if you need to re-pull the item later? So kind of like you're doing a selective sync? I'm going to check with engineering on this.

Correct. I keep the change key in a db, so I only re-fetch what is absolutely necessary. Keeps bandwidth usage and load on the exchange server down to a minimum.

Thank you Jason for checking it out deeper at your end.

Erez

Any update?